The present invention relates to computers capable of concurrently executing programs written for different operating system environments.
There is a need in the marketplace for a personal computer capable of executing computer programs written for different operating system environments. On the one hand, users may wish to avail themselves of, for example, such benefits of UNIX.RTM. operating system as multi-tasking and various useful utilities. On the other hand, the vast bulk of the personal computer application software available today is written for the MS-DOS.RTM. operating system.
Designing a computer capable of supporting two (or more) operating systems and executing their respective applications would not be particularly difficult if they are to operate in a single tasking environment. Both operating systems could be installed in memory and program control given to a particular one or the other of them depending on the software to be run. When the desire is to support two operating systems in a multi-tasking environment, however, the design problem can be significantly more complex--particularly, as will be seen, if one wants as a goal the ability to run the many software packages available for the IBM personal computer line, hereinafter referred to as the IBM-compatible software, which requires an MS-DOS system operating environment.
In particular, an important consideration in any multi-tasking system is to ensure that the various concurrently executing programs do not interfere with each other by, for example, attempting to write in the same memory space or to use the same peripheral device, such as a printer or disk drive, at the same time. To this end, microprocessors have been designed for use as the central processing units (CPUs) of personal computers wherein the microprocessor is provided with a so-called "protected mode" of operation. This mode provides a mechanism for, for example, allocating different areas of memory to the various concurrently executing programs and to otherwise prevent them from interfering with one another.
It thus might seem that a possible approach for allowing programs written for different operating systems or, indeed, programs of any type, to execute concurrently would be to simply run them all in a protected mode. As a practical matter, however, this solution may be unworkable. For example, the IBM-compatible software is written for an MS-DOS system environment as ported to an Intel microprocessor such as the 8086 or 8088. At a minimum, then, a multi-tasking computer that is to run that software should also be of the Intel family. The 80286, for example, is an Intel microprocessor which has a protected mode--indeed, it is currently the only Intel microprocessor having same--and could thus be used in such applications. Unfortunately, the so-called "segment" registers in the 80286 are defined differently when the microprocessor is operating in its protected mode from the way the segment registers are defined in the 8086 and 8088. As a result, software written for the 8086 or 8088, such as the IBM-compatible software, will not execute properly in the 80286 in protected mode. The 80286 does have a second operating mode, in which the operation of the 8086 and 8088 is emulated, that mode being referred to as the "real addressing mode" or, more simply, the "real mode." That mode, however, is a non-protected mode, and thus will not support a safe multi-tasking environment. Moreover, although it might seem possible to (a) run the IBM-compatible software in protected mode and (b) trap all segment register references and reload those registers with the appropriate values for protected mode operation, this may not be a practical solution because, for example, it would severely compromise performance and may be very difficult to implement for all cases.
In a similar vein, one might think of preprocessing any software written for real mode execution--hereinafter referred to as "real mode software"--to convert all segment register references to protected mode versions thereof. This is also not a practical solution because it would require being able to differentiate between programming and data in disassembled code--something that is not, in general, possible to do.
Moreover, running the real mode software in a separate processor, such as a separate 8086 or 8088, is not a wholly acceptable solution because unless one is willing to provide separate memories and peripherals for each of the processors, there remains a problem of how the various concurrently running programs are to share those resources.
A further problem to be taken into account is that, in order to speed up system response, much of the IBM-compatible software accesses the various computer peripherals not through established MS-DOS system calls but, rather, by (a) addressing the peripherals directly and/or (b) directly addressing the interface, referred to as Basic Input/Output System, or BIOS, between the MS-DOS operating system and the peripherals. Thus any approach that would simply prevent the MS-DOS operating system from accessing, on behalf of an executing application, memory and peripherals being used by other, concurrently executing applications would be an incomplete solution to the problem of how the IBM-compatible software could be executed in a multi-tasking environment, because the aforementioned programs will, unless prevented from doing so, access memory and peripherals on their own.